6장. 네 가지 바이브 코딩 사례 연구

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 6장 (pp. 127~136). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

개인 취미 프로젝트부터 3000명 규모의 엔터프라이즈 조직까지, 네 가지 실제 사례를 통해 바이브 코딩이 현장에서 어떻게 FAAFO를 만들어내는지 — 그리고 무엇이 성공과 실패를 갈랐는지 — 를 살펴본다.

학습 목표

이 장을 끝내면 다음을 할 수 있다. - 네 가지 사례(개인 2건·엔터프라이즈 2건) 각각에서 무엇이 성공과 실패를 갈랐는지 구분한다. - 숙련된 개발자가 도구·인증 경로 선택에서 발휘하는 판단력이 바이브 코딩 성공에 기여하는 방식을 설명한다. - 아디다스의 실패한 1차 파일럿과 성공한 2차 파일럿을 비교해 그 차이를 분석한다. - 부킹닷컴 사례에서 "도구 도입"과 "도구 채택"이 왜 다른 문제인지 식별한다. - 네 사례에 공통으로 나타나는 성공 요인을 종합해 자신의 프로젝트에 적용한다.

전체 흐름도

              네 가지 바이브 코딩 사례 연구
                          │
     ┌──────────────┬──────────────┬──────────────┐
     ▼              ▼              ▼              ▼
  루크 버튼      크리스틴 허드슨    아디다스        부킹닷컴
 (개인·취미)     (개인·복귀)     (엔터프라이즈1)  (엔터프라이즈2)
     │              │              │              │
 CNC 펌웨어      구글 캘린더     700명 GenAI      개발자
 업로더 자동화    내보내기        파일럿          생산성 향상
     │              │              │              │
 압축 파일       세 갈래 동시    1차: 90% 실패    피처 플래그
 처리에서 막힘    시도 — 인증     (도구·모델        부채 → 소스
     │            뚫린 경로만     미성숙기)         그래프 도입
 커서로 전환      성공(크리스틴)      │              │
 (같은 모델)         │           2차: 70% 생산성   채택 저조 →
     │          숙련자의 강점=    향상, 행복한       교육·해커톤
     ▼          "막힘을 아는 것"  시간 +50%           │
 두 번째 시도                        │           머지↑30%·
   성공                              ▼           리뷰시간↓
     └──────────────┴──────┬───────┴──────────────┘
                            ▼
        결론 — 맥락과 규모는 다르지만, 감독을 거친 위임과
        올바른 조건(아키텍처·피드백 루프·교육)이 성공을 가른다

0. 용어 사전

참고 — 위쪽 4개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 앞 장을 먼저 확인한다.

1. 왜 네 가지 사례인가

바이브 코딩을 뒷받침하는 기법과 프레임워크를 본격적으로 다루기 전에, 이 장은 현장 기반의 주요 사례 넷을 먼저 살펴본다. 숙련된 개발자 한 명이 사이드 프로젝트에 도전한 사례, 거의 20년 동안 프로그래밍에서 손을 뗐던 사람이 바이브 코딩으로 자신의 문제를 해결한 사례, 그리고 세계적인 수준의 두 엔지니어링 팀이 바이브 코딩으로 중요한 비즈니스 문제를 해결한 사례다.

이 일화들은 사람들이 실제로 FAAFO를 달성하는 과정을 담고 있다. 개인의 취미 프로젝트부터 수천 명 규모의 엔지니어링 조직까지, 바이브 코딩이 기술 조직 전반에 걸쳐 규모 있게 확산될 때 어떤 변화와 잠재력이 있을지를 이 네 사례를 통해 가늠해볼 수 있다.

2. 루크 버튼 — CNC 머신을 위한 OSS 펌웨어 업로더 구축

루크 버튼은 애플에서 엔지니어링 매니저로 20년을 근속하며 애플의 주요 순간을 만들어낸 인물이다. 2014년 WWDC에서 수백만 명의 개발자에게 스위프트 프로그래밍 언어를 소개할 당시 기술 총괄 책임자였고, iOS·macOS 생태계의 수많은 시스템을 다뤘으며 아이폰 공급망 보안 개선에도 참여했다.

최근 루크는 CNC 머신을 다루는 취미에 빠졌다. CNC 머신은 칼날 끝처럼 날카로운 정밀도로 복잡한 금속 부품을 깎아내는 정교한 장치인데, 펌웨어 개발 환경이 몹시 까다로웠다. 루크는 펌웨어를 테스트할 때 개발자 노트북에서 로컬로 하는 것이 아니라 CNC 머신 자체에서 테스트를 수행해야 한다는 사실을 알게 되었다. 여기에 펌웨어를 업로드하려면 복잡한 telnet 명령어가 필요했고, 단위 테스트는 거의 흔적만 남아 있어 코드를 수정하는 일 자체가 위험하고 불쾌하게 느껴질 지경이었다.

루크는 클로드 코드를 사용해 CNC 도구와 코드베이스를 탐색하고 수정을 시작할 수 있다는 것을 스스로 증명했다. 곧이어 펌웨어를 CNC 머신에 업로드하는 과정을 자동화하는 파이썬 프로그램까지 작성했다 — "문서가 준비된, 제대로 된 CLI 옵션을 갖춘 2600줄짜리 파이썬 기반 도구"였다. 클로드 코드 토큰에 50달러를 썼고, 작업 자체는 멀티태스킹을 하면서 두 시간 만에 끝났다. 반응을 본 협업자들은 열광했고, 루크는 "15분만 더 투자하면 GNU 리드라인 기반 인터랙티브 모드를 지원할 수 있다"며 자신감을 보였다. 기존 CNC 컨트롤러 프로그램은 복사·붙여넣기조차 안 되고 파일 열기 메뉴도 없이 악명이 높았기에, 다른 사람들도 이 도구를 원했다.

물론 모든 것이 한 번에 해결되지는 않았다. 클로드 코드는 원래 CNC 펌웨어가 참조하던 이상하게 압축된 파일들을 처리하는 데 어려움을 겪었다. 루크는 결국 클로드 코드와 동일한 클로드 소네트 3.7 모델을 쓰는 커서로 전환해, 이미 잘 작동하던 파이썬 프로그램을 그대로 입력하고 두 번의 시도 끝에 문제를 해결했다.

판단 시나리오 — 상황: 클로드 코드로 CNC 펌웨어 도구를 거의 완성했지만, 원래 펌웨어가 참조하던 이상하게 압축된 파일 처리에서 막혔다. 잘못된 접근: 같은 도구로 계속 씨름하며 시간을 쓴다. 올바른 접근: 이미 동작이 검증된 결과물(파이썬 프로그램)을 그대로 들고, 같은 모델(클로드 소네트 3.7)을 쓰는 다른 도구(커서)로 옮겨 다시 시도했다. 왜: 막힘의 원인이 모델 자체의 한계가 아니라 특정 도구의 특정 처리 방식에 있을 수 있고, 결과물은 도구에 종속되지 않으므로 옮겨서 다시 시도하는 비용이 처음부터 다시 짜는 것보다 훨씬 낮다.

루크의 사례는 또 하나의 FAAFO 달성이다. 여러 도구를 영리하게 조합해 작동하는 소프트웨어를 완성한 사례이자, CNC 펌웨어 개선에 참여하는 모든 사람이 더 잘·더 빠르게·더 안전하게 작업하도록 기여한 사례로 남는다.

3. 크리스틴 허드슨 — 다시 코딩을 시작하다

저자들의 친구인 크리스틴 허드슨은 2004년 머신러닝으로 석사 과정을 마쳤지만 15~20년 가까이 코딩을 하지 않았다. 그런 그녀가 바이브 코딩을 시도해보기로 결심했다.

크리스틴이 고른 첫 프로젝트는 자신의 구글 캘린더 일정을 다른 구글 계정으로 내보내는 작업이었다 — AI가 없었다면 절대 시도하지 않았을 일이고, FAAFO의 '야심 찬(Ambitious)' 작업에 해당한다. 저자들은 크리스틴과 함께 어떤 개발 환경이 이 작업에 가장 적합할지 골라야 했다. 로컬 개발 환경 설정은 되도록 피하고 싶어, 구글 앱 스크립트·구글 코랩 노트북·터미널 애플리케이션 세 갈래를 동시에 시도했다. 셋의 목표는 같았다 — 90분 안에 작동하는 무언가를 만드는 것. 하지만 접근 방식은 각자 달랐다.

뜻밖에도 크리스틴이 작업을 가장 먼저 완료했을 뿐 아니라 유일하게 성공시켰다. 그녀는 구글 앱 스크립트로 자신의 캘린더를 구글 드라이브에 ICS 캘린더 파일로 내보내는 데 성공했다. 반면 스티브는 실시간으로 재현을 시도했지만 인증과 관련된 알기 어려운 에러로 실패했고, 진은 구글 코랩 노트북에서 파이썬으로 시도하다가 구글 인증(OAuth) 동의 화면을 생성하는 지점에서 비슷하게 막혔다. 저자 둘은 모든 프로그래머가 마주치는 가시 철망 — 상호작용이 필요하지만 통제할 수 없는 제삼자 API — 에 걸려 실패한 셈이다.

판단 시나리오 — 상황: 구글 캘린더 일정을 다른 계정으로 옮기는 작업에 구글 앱 스크립트·구글 코랩·터미널 애플리케이션 세 가지 접근이 동시에 시도됐다. 잘못된 접근(저자 둘의 선택): 코랩·터미널에서 처음부터 새로 구글 OAuth 인증 동의 화면을 만들려다 알기 어려운 에러에 막혔다. 올바른 접근(크리스틴의 선택): 이미 인증이 끝나 있고 구글 캘린더 API 접근 권한이 있는 구글 앱 스크립트를 골랐다. 왜: 바이브 코딩에서 막히는 지점은 종종 코드 로직이 아니라 인증처럼 통제할 수 없는 외부 상호작용이다. 이미 뚫려 있는 경로를 아는 것이 숙련된 개발자의 진짜 강점이다.

이 통찰 — 인증 복잡성을 피할 경로를 아는 것 — 은 숙련된 개발자의 진짜 강점을 보여준다. 다양한 기술 생태계를 알고 어떤 접근이 다른 접근보다 나은지 판단력을 쌓아온 것이다. 물론 시니어가 잘못된 방식을 고르고 주니어가 올바른 것을 고를 때도 있지만, 적어도 누군가는 성공하니 괜찮다.

크리스틴은 이 경험을 10점 만점(최고의 경험) 기준으로 "10점 이상"이라고 평가했다 — 요구에 맞춰 코드가 자동으로 만들어지는 모습이 마법 같았다고 했다. 가장 좌절스러웠던 순간을 묻자, 실패한 구글 클라우드 가입, 수많은 에러 메시지, 클로드의 사용량 제한, ChatGPT로의 전환, 스크린숏 업로드 불가 등 외부적 장애물을 꼽았다. 그러나 이것들이 자신이 매일 겪는 컴퓨터 문제 해결보다 더 성가시지는 않았다고 말했다. 오히려 저자들이 크리스틴보다 더 큰 좌절을 느꼈는데, 순조로울 거라 예상한 과정에 장애물이 많았기 때문이다. 스티브는 "바이브 코딩은 모든 놀이기구가 0.5초로 압축되고 남는 것은 줄서서 기다리는 것뿐인 디즈니랜드 여행과 같을 수 있다"고 농담했다. 그런데도 크리스틴은 좌절 속에서 보람을 찾았고 자신이 만든 것에 자부심을 느꼈다 — 진정한 FAAFO였다.

4. 700명의 아디다스 개발자 사례

루크와 크리스틴의 취미 프로젝트만 보면 바이브 코딩이 엔터프라이즈의 진짜 업무에는 맞지 않는다고 여길 수 있다. 그 점을 염두에 두고 저자들은 아디다스의 글로벌 디지털·이커머스 기술 부문 부사장으로서 거의 1000명에 달하는 개발자를 책임지고 있는 페르난도 코르나고의 사례를 살펴본다. 아디다스는 연간 90억 유로의 매출을 올리며 전 세계 이커머스 브랜드 상위 5위 안에 드는 기업이다.

2024년과 2025년에 걸쳐 페르난도는 700명 규모의 생성형 AI(GenAI) 개발자 파일럿 프로젝트에 대한 보고서를 발표했다. 이는 아디다스의 두 번째 파일럿이었다 — 첫 번째 파일럿은 90%의 개발자가 코딩 어시스턴트 도구를 경멸할 정도로 처참하게 실패했다. "완전한 시간 낭비"라거나 "급한 불 끄기와 트러블슈팅만 남았다"는 악평이 쏟아졌다. 이는 AI 기반 코딩의 개척기(2024년 초)에 흔했던 현실로, 당시에는 도구와 모델이 유용하다고 말할 수 있을 만큼 충분히 성숙하지 않았다.

이 교훈을 바탕으로 아디다스는 다시 파일럿을 시도했다. 두 번째 파일럿은 2년 차에 접어들고 있으며, 개발자의 70%가 20~30%의 생산성 향상(커밋 수·풀 리퀘스트 수·전반적 기능 개발 속도 기준)을 경험했다는 고무적인 결과가 나왔다. 개발자들은 일상 작업에서 20~25% 더 효과적으로 느꼈다고 답했다 — 10배 더 강력한 코딩 에이전트가 등장하기 전에 나온 수치라는 점에서 더욱 인상적이다.

판단 시나리오 — 상황: 1차 파일럿에서 90%의 개발자가 코딩 어시스턴트 도구를 "완전한 시간 낭비"라 평가하며 처참하게 실패했다(2024년 초, AI 코딩 도구·모델이 아직 충분히 성숙하지 않았던 시기). 잘못된 접근: 실패한 결과만 보고 "바이브 코딩이 우리 조직에 안 맞는다"고 결론짓는다. 올바른 접근: 그 교훈을 바탕으로 다시 설계한 2차 파일럿을 시도해, 2년 차에 개발자 70%가 20~30% 생산성 향상을 보고하는 결과를 얻었다. 왜: 실패의 원인이 "바이브 코딩 자체가 안 맞음"이 아니라 "그 시점의 도구·모델 성숙도"였을 수 있다는 것을 재시도가 증명했다.

페르난도는 엔지니어 대부분의 '행복한 시간'이 50% 증가했다는 사실을 자랑스러워했다. 행복한 시간은 개발자가 직접적인 코딩·분석·설계처럼 하고 싶은 일에 쓰는 시간을 뜻하고, 그만큼 회의 참석·환경 문제 해결·취약한 테스트 처리·지루한 행정 업무 같은 '짜증 나는 시간'이 줄었다는 의미다. 더 행복한 팀은 느슨하게 결합된 아키텍처에서 일하고, 명확한 API 경계·빠른 피드백 루프·행동의 자율성을 갖춘다는 공통점이 있다 — 바이브 코딩은 이런 환경에서 잘 작동한다. 즉 올바른 아키텍처와 빠른 피드백 루프가 갖춰질 때 바이브 코딩은 생산성과 직무 만족도를 함께 높일 수 있다.

5. 부킹닷컴의 개발자 생산성 향상 사례

부킹닷컴은 3000명 이상의 개발자를 보유한 세계 최대 규모의 온라인 여행사 중 하나다. 개발자 경험을 담당하는 조직의 프로덕트 매니저 브루노 파소스의 사명은 개발자들이 최고의 성과를 낼 수 있도록 방해 요소를 제거하는 것이다.

부킹닷컴은 실험 문화에 유서 깊은 역사를 가지고 있다. 거의 모든 기능을 피처 플래그를 통한 테스트로 결정하는데, 하나의 기능에 여러 버전을 동시에 프로덕션에 배포한 뒤 어떤 버전이 비즈니스 목표를 가장 잘 달성하는지 측정하는 방식이다. 그러나 부작용도 있다 — 코드베이스에는 비활성화된 피처 플래그 뒤에 숨은 한 번도 쓰이지 않는 기능, 레거시 코드, 오래된 실험이 쌓였다. 개발자들은 이 부작용 때문에 생산적인 코딩이 아니라 좌절을 유발하는 잡무에 전체 시간의 90%를 쓰고 있었다.

부킹닷컴은 소스그래프의 AI 코드 어시스턴트와 검색 도구를 사용해 이 문제를 푸는 데 집중했다. 결과적으로 개발자들은 코딩 효율이 30% 향상되었다고 보고했고, 머지 요청은 70% 더 작아졌으며 리뷰 시간도 감소했다.

부킹닷컴도 초반엔 내부 엔지니어들의 채택이 고르지 않았다 — 일부는 새 AI 파트너를 받아들였지만 대다수는 이점을 느끼지 못했다. 브루노와 개발자 경험 팀은 빠져 있던 핵심 요소가 교육이라는 사실을 깨달았다.

판단 시나리오 — 상황: 소스그래프의 AI 코드 어시스턴트·검색 도구를 도입했지만 초반엔 일부 개발자만 받아들였고 대다수는 이점을 느끼지 못했다. 잘못된 접근: 도구만 배포하면 채택이 자연히 따라올 것이라 가정하고 기다린다. 올바른 접근: 빠져 있던 핵심 요소가 교육이라는 것을 깨닫고, 개발자들에게 코딩 어시스턴트에게 더 명확한 지시와 더 효과적인 콘텍스트를 제공하는 방법을 가르치는 교육 이니셔티브·해커톤·워크숍을 만들었다. 왜: 도구 도입과 도구 채택은 다른 문제다 — 능력이 아니라 습관과 방법을 모르는 것이 채택을 막을 수 있다.

그 결과 머지 요청 수가 최대 30%까지 증가하고 직무 만족도도 높아지는 가시적 성과가 나타났다. 브루노의 리더십 아래 부킹닷컴은 더 빠른 머지, 더 높은 품질의 코드, 기술 부채 감소에 초점을 맞춘 단기·중기·장기 목표를 정의했다. 소스그래프의 툴에 특화된 에이전트들은 개발자들이 30% 더 많은 머지 요청을 더 작은 변경 diff 단위로 커밋하도록 도왔고 리뷰 시간도 줄여주었다. 브루노는 툴 도입만으로는 충분하지 않다는 점을 강조했다 — 맞춤형 실습 중심 해커톤과 워크숍을 통한 전폭적 지원이 있었기에, 처음엔 주저하던 개발자들까지 열정적인 바이브 코더로 거듭나 FAAFO를 만났다.

6. 결론

취미 프로젝트부터 엔터프라이즈 규모까지 아우르는 네 가지 사례는 서로 다른 맥락과 기술 수준에 걸쳐 바이브 코딩이 어떤 잠재력을 보여줄지를 나타낸다. 루크의 CNC 펌웨어 프로젝트는 개인 개발자가 새롭게 얻은 효율성으로 얼마나 야심 찬 목표를 달성할 수 있는지 보여준다. 20년의 공백 이후 코딩으로 돌아온 크리스틴은 한때 프로그래밍에서 멀어졌던 사람도 바이브 코딩으로 다시 코딩을 즐길 수 있다는 자신감을 심어준다. 아디다스와 부킹닷컴의 사례는 올바른 조건이 갖춰질 경우 대규모 조직에서도 개발자 생산성·행복도·비즈니스 성과를 체계적으로 향상시킬 수 있음을 보여준다.

네 사례를 관통하는 공통점은 하나다 — 개인이든 조직이든, 성공은 우연이 아니라 막힘을 알아채고(도구 전환·인증 경로·재설계·교육) 그에 맞게 조정하는 판단에서 나왔다. 다음 장은 이 혁신적인 접근 방식을 실제로 활용하는 데 필요한 기법과 프레임워크를 살펴본다.

핵심 개념 정리

실무 체크리스트

• [ ] 한 도구가 특정 처리에서 막혔을 때, 검증된 결과물을 다른 도구로 옮겨 다시 시도할 수 있는 형태로 만들었는가?
• [ ] 새 통합 작업을 시작하기 전에, 이미 인증·권한이 확보된 경로가 있는지 먼저 확인했는가?
• [ ] 파일럿이 실패했을 때 "접근 자체가 안 맞다"와 "그 시점의 도구·모델이 미성숙했다"를 구분해서 판단했는가?
• [ ] 도구 채택률이 낮을 때, 능력 문제가 아니라 교육·습관 문제일 가능성을 먼저 점검했는가?
• [ ] 실험(피처 플래그 등)이 끝난 뒤 비활성화된 코드를 정리하는 절차가 있는가?
• [ ] 팀의 "행복한 시간"과 "짜증 나는 시간"이 실제로 무엇으로 채워지는지 파악하고 있는가?
• [ ] 큰 조직에 바이브 코딩을 도입하기 전에, 느슨한 결합 아키텍처·명확한 API 경계·빠른 피드백 루프가 갖춰져 있는지 점검했는가?

연습문제

1. 적용형. 팀원이 AI 코딩 에이전트로 어떤 파일 처리 작업을 시도하다가 특정 압축 포맷에서 반복적으로 실패하고 있다. 루크의 사례를 참고해 다음으로 시도해 볼 수 있는 방법을 제안하라.
2. 판단형. 새 프로젝트에서 외부 서비스 API에 접근해야 하는데, 하나는 이미 인증이 끝난 환경에서 실행하는 방법이고 다른 하나는 처음부터 새로 OAuth 인증을 구성하는 방법이다. 크리스틴의 사례에 비추어 어느 쪽을 먼저 시도해야 하며 그 이유는 무엇인가?
3. 분석형. 당신 회사가 1차로 시도한 AI 코딩 도구 파일럿이 처참하게 실패했다. 아디다스 사례를 참고해, 이 실패가 "바이브 코딩 자체의 한계"인지 "다른 원인"인지 판단하려면 무엇을 먼저 확인해야 하는가?
4. 적용형. 팀에 AI 코드 어시스턴트를 도입했는데 몇 달이 지나도 채택률이 낮다. 부킹닷컴의 사례를 참고해 원인을 진단하고 취할 수 있는 조치를 제안하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장 §5가 언급한 소스그래프는 책 출간 후 조직이 갈라졌다. 부킹닷컴의 사례 자체(실험 문화·피처 플래그 부채·도입 후 교육을 통한 채택 개선)는 그대로 유효하다. - 소스그래프가 두 회사로 갈라졌다. 2025년 12월 2일, 소스그래프는 코드 검색·엔터프라이즈 플랫폼 사업(신임 CEO 댄 애들러)과 에이전트형 코딩 도구 "Amp"(공동창업자 퀸 슬랙·비양 리우가 이끄는 독립 회사 Amp Inc.)로 분리됐다. 부킹닷컴의 사례가 있었던 시점에는 한 회사였고 이 장의 서술은 그대로 유효하다 — 다만 오늘 "소스그래프의 AI 코드 어시스턴트"를 찾는다면 어느 조직 소관인지 구분해야 한다. Sourcegraph 공식 블로그 · Amp 공식 발표

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• 소스그래프 공식 블로그 — 두 회사 분리 발표 — Why Sourcegraph and Amp are becoming independent companies
• Amp 공식 발표(공동창업자 서한) — Amp Frontier Corporation
• 구글 앱 스크립트 공식 문서 — 크리스틴이 쓴 도구의 현재 기능을 확인할 때. Google Apps Script

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 루크의 사례(§2)는 문제가 반드시 모델이나 접근법 자체의 한계가 아니라 특정 도구의 특정 파일 처리 방식에 있을 수 있음을 보여준다. 이미 동작을 확인한 결과물(코드)을 그대로 들고, 같은 모델을 쓰는 다른 도구로 옮겨 다시 시도해 볼 수 있다 — 도구를 바꾸는 비용이 처음부터 다시 짜는 것보다 훨씬 낮다.
2. (문제 2 정답) 이미 인증이 끝난 환경을 먼저 시도해야 한다. 크리스틴의 사례(§3)에서 저자 둘은 새로 OAuth 인증 화면을 구성하려다 막혔지만, 크리스틴은 이미 구글 캘린더 API 접근 권한이 있는 구글 앱 스크립트를 선택해 유일하게 성공했다. 바이브 코딩에서 막히는 지점은 종종 코드 로직이 아니라 통제할 수 없는 외부 인증이므로, 이미 뚫려 있는 경로를 아는 것이 가장 확실한 지름길이다.
3. (문제 3 정답) 아디다스의 1차 파일럿(§4)도 90%가 도구를 경멸할 정도로 실패했지만, 원인은 "바이브 코딩 자체"가 아니라 "AI 코딩의 개척기(2024년 초)였고 도구·모델이 아직 충분히 성숙하지 않았던 시점"이었다. 확인해야 할 것은 실패가 도구·모델의 성숙도 때문인지, 팀의 준비(교육·가드레일) 부족 때문인지, 작업 성격(요구사항 명확성) 때문인지다. 이를 바탕으로 재설계한 2차 파일럿에서 아디다스는 실제로 70%의 생산성 향상을 확인했다.
4. (문제 4 정답) 부킹닷컴의 사례(§5)를 보면, 도구(소스그래프의 AI 코드 어시스턴트)를 도입한 것만으로는 채택이 따라오지 않았다. 빠져 있던 핵심 요소는 교육이었다 — 개발자들에게 코딩 어시스턴트에게 더 명확한 지시와 콘텍스트를 제공하는 방법을 가르치는 교육 이니셔티브와 해커톤·워크숍을 마련한 뒤에야 머지 요청이 최대 30%까지 늘고 직무 만족도도 높아졌다.